GGGGLLLL____QQQQUUUUAAAADDDD____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE8888____SSSSGGGGIIIISSSS, GGGGLLLL____QQQQUUUUAAAADDDD____IIIINNNNTTTTEEEENNNNSSSSIIIITTTTYYYY4444____SSSSGGGGIIIISSSS, or
GGGGLLLL____AAAABBBBGGGGRRRR____EEEEXXXXTTTT, GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE, and GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA.
_t_y_p_e Specifies the data type of the pixel data. The following
symbolic values are accepted: GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE, GGGGLLLL____BBBBYYYYTTTTEEEE,
GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____SSSSIIIIZZZZEEEE____EEEEXXXXTTTT, and GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____IIIINNNNTTTTEEEENNNNSSSSIIIITTTTYYYY____SSSSIIIIZZZZEEEE____EEEEXXXXTTTT), but no
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____8888____8888____8888____8888____EEEEXXXXTTTT, or GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____11110000____11110000____11110000____2222____EEEEXXXXTTTT then it is
a special case in which all the elements of each group are packed into a
single unsigned byte, unsigned short, or unsigned int. This is described
in ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss.)
The first element corresponds to the lower-left-rear corner of the
texture volume. Subsequent elements progress left-to-right through the
remaining texels in the lowest-rear row of the texture volume, then in
successively higher rows of the rear 2D slice of the texture volume, then
in successively closer 2D slices of the texture volume. The final
element corresponds to the upper-right-front corner of the texture
volume.
When GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is enabled, only rows (0,2,4,...) of each S-T
slice (where the border is considered part of the slice) are defined.
Rows (1,3,5,...) are left undefined and can only be defined using
ggggllllTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee3333DDDDEEEEXXXXTTTT or ggggllllCCCCooooppppyyyyTTTTeeeexxxxSSSSuuuubbbbIIIImmmmaaaaggggeeee3333DDDDEEEEXXXXTTTT. Note, that when
GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is enabled the total height (i.e., the height of
interior texture image plus twice the border) of the defined texture is
2*height.
Each element of _p_i_x_e_l_s is converted to an RGBA element according to
_f_o_r_m_a_t, as detailed below. Except for GGGGLLLL____CCCCOOOOLLLLOOOORRRR____IIIINNNNDDDDEEEEXXXX, after the
conversion to RGBA, each component is multiplied by the signed scale
factor GGGGLLLL____cccc____SSSSCCCCAAAALLLLEEEE, added to the signed bias GGGGLLLL____cccc____BBBBIIIIAAAASSSS, and clamped to the
range [0,1], where cccc is RRRREEEEDDDD, GGGGRRRREEEEEEEENNNN, BBBBLLLLUUUUEEEE, or AAAALLLLPPPPHHHHAAAA, respectively (see
Each element is a single value, a color index. It is converted
to fixed point (with an unspecified number of zero bits to the
right of the binary point), shifted left or right depending on
the value and sign of GGGGLLLL____IIIINNNNDDDDEEEEXXXX____SSSSHHHHIIIIFFFFTTTT, and added to
GGGGLLLL____IIIINNNNDDDDEEEEXXXX____OOOOFFFFFFFFSSSSEEEETTTT (see ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrr). The resulting index is
Each element is a luminance/alpha pair. It is converted to
floating point, then assembled into an RGBA element by
replicating the luminance value three times for red, green, and
blue.
Please refer to the ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss reference page for a description of the
acceptable values for the _t_y_p_e parameter.
An application may desire that the texture be stored at a certain
resolution, or that it be stored in a certain format. This resolution and
format can be requested by _i_n_t_e_r_n_a_l_f_o_r_m_a_t, but the implementation may not
support that resolution (The formats of GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE, GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA,
GGGGLLLL____RRRRGGGGBBBB, and GGGGLLLL____RRRRGGGGBBBBAAAA must be supported.) When a resolution and storage
format is specified, the implementation will update the texture state to
provide the best match to the requested resolution. The
GGGGLLLL____PPPPRRRROOOOXXXXYYYY____TTTTEEEEXXXXTTTTUUUURRRREEEE____3333DDDD____EEEEXXXXTTTT target can be used to try a resolution and
format. The implementation will compute its best match for the requested
storage resolution and format; this state can then be queried using
A one-component texture image uses only the red component of the RGBA
color extracted from _p_i_x_e_l_s. A two-component image uses the R and A
values. A three-component image uses the R, G, and B values. A four-
component image uses all of the RGBA components.
The mapping of components from the canonical RGBA to the internal storage
formats that begin with GGGGLLLL____DDDDUUUUAAAALLLL____ and GGGGLLLL____QQQQUUUUAAAADDDD____ needs to be clarified.
There are three cases. The first case is for the GGGGLLLL____DDDDUUUUAAAALLLL____ formats that
are groups of GGGGLLLL____AAAALLLLPPPPHHHHAAAA, GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE, and GGGGLLLL____IIIINNNNTTTTEEEENNNNSSSSIIIITTTTYYYY. The R value goes
to the first group while the A value goes to the second group. The
second case is for the GGGGLLLL____DDDDUUUUAAAALLLL____ formats that are groups of
GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA. The R and G values go to the first group while the B
and A values go to the second group. The third case is for the GGGGLLLL____QQQQUUUUAAAADDDD____
formats. The R value goes to the first group, the G value to the second
group, the B value to the third group, and the A value to the fourth
group.
NNNNOOOOTTTTEEEESSSS
Texturing has no effect in color index mode.
The texture image can be represented by the same data formats and types
as the pixels in a ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss command, except that formats
GGGGLLLL____SSSSTTTTEEEENNNNCCCCIIIILLLL____IIIINNNNDDDDEEEEXXXX and GGGGLLLL____DDDDEEEEPPPPTTTTHHHH____CCCCOOOOMMMMPPPPOOOONNNNEEEENNNNTTTT cannot be used, and type
GGGGLLLL____BBBBIIIITTTTMMMMAAAAPPPP cannot be used. ggggllllPPPPiiiixxxxeeeellllSSSSttttoooorrrreeee and ggggllllPPPPiiiixxxxeeeellllTTTTrrrraaaannnnssssffffeeeerrrr modes affect
texture images in exactly the way they affect ggggllllDDDDrrrraaaawwwwPPPPiiiixxxxeeeellllssss.
A texture image with zero height, width, or depth indicates the null
texture. If the null texture is specified for level-of-detail 0, it is
as if texturing were disabled.
ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee3333DDDDEEEEXXXXTTTT is part of the EEEEXXXXTTTT____tttteeeexxxxttttuuuurrrreeee3333dddd extension.
If _t_y_p_e is set to GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____BBBBYYYYTTTTEEEE____3333____3333____2222____EEEEXXXXTTTT,
GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____8888____8888____8888____8888____EEEEXXXXTTTT, or GGGGLLLL____UUUUNNNNSSSSIIIIGGGGNNNNEEEEDDDD____IIIINNNNTTTT____11110000____11110000____11110000____2222____EEEEXXXXTTTT and the
EEEEXXXXTTTT____ppppaaaacccckkkkeeeedddd____ppppiiiixxxxeeeellllssss extension is not supported then a GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____EEEENNNNUUUUMMMM error
is generated.
See ggggllllIIIInnnnttttrrrroooo for more information on using extensions.
EEEERRRRRRRROOOORRRRSSSS
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____EEEENNNNUUUUMMMM is generated when _t_a_r_g_e_t is not an accepted value.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____EEEENNNNUUUUMMMM is generated when _f_o_r_m_a_t is not an accepted value.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____EEEENNNNUUUUMMMM is generated when _t_y_p_e is not an accepted value.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if _l_e_v_e_l is less than zero or greater than
log (_m_a_x), where _m_a_x is the returned value of GGGGLLLL____MMMMAAAAXXXX____3333DDDD____TTTTEEEEXXXXTTTTUUUURRRREEEE____SSSSIIIIZZZZEEEE____EEEEXXXXTTTT.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if _i_n_t_e_r_n_a_l_f_o_r_m_a_t is not an accepted value.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if _w_i_d_t_h, _h_e_i_g_h_t, or _d_e_p_t_h is less than
zero or greater than GGGGLLLL____MMMMAAAAXXXX____3333DDDD____TTTTEEEEXXXXTTTTUUUURRRREEEE____SSSSIIIIZZZZEEEE____EEEEXXXXTTTT, when _w_i_d_t_h, or _d_e_p_t_h
cannot be represented as 2**k+2*border for some integer k, or when _h_e_i_g_h_t
cannot be represented as 2**k+I*border, where I is 2 when
GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is disabled and 1 otherwise.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if _b_o_r_d_e_r is not 0 or 1.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____OOOOPPPPEEEERRRRAAAATTTTIIIIOOOONNNN is generated if ggggllllTTTTeeeexxxxIIIImmmmaaaaggggeeee3333DDDDEEEEXXXXTTTT is executed between
the execution of ggggllllBBBBeeeeggggiiiinnnn and the corresponding execution of ggggllllEEEEnnnndddd.
GGGGLLLL____IIIINNNNVVVVAAAALLLLIIIIDDDD____VVVVAAAALLLLUUUUEEEE is generated if the implementation cannot accomodate a
ggggllllIIIIssssEEEEnnnnaaaabbbblllleeeedddd with argument GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____3333DDDD____EEEEXXXXTTTT
ggggllllGGGGeeeettttTTTTeeeexxxxLLLLeeeevvvveeeellllPPPPaaaarrrraaaammmmeeeetttteeeerrrr with a first argument of GGGGLLLL____PPPPRRRROOOOXXXXYYYY____TTTTEEEEXXXXTTTTUUUURRRREEEE____3333DDDD____EEEEXXXXTTTT
and a third argument of GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____RRRREEEEDDDD____SSSSIIIIZZZZEEEE____EEEEXXXXTTTT,
GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____DDDDEEEEPPPPTTTTHHHH____EEEEXXXXTTTT, GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____BBBBOOOORRRRDDDDEEEERRRR, or GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____CCCCOOOOMMMMPPPPOOOONNNNEEEENNNNTTTTSSSS.
RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems do not support color
matrix transformations on images as they are loaded to or read back from
texture memory.
RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems do not support convolving
images as they are loaded into texture memory.
RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems do not support histogram
or minmax operations on images as they are being loaded into texture
memory.
The SSSSGGGGIIIIXXXX____iiiinnnntttteeeerrrrllllaaaacccceeee extension is supported only on IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy
systems, on RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems, on OOOOccccttttaaaannnneeee2222
VVVVPPPPrrrroooo systems, and on OOOO2222 systems.
The EEEEXXXXTTTT____ppppaaaacccckkkkeeeedddd____ppppiiiixxxxeeeellllssss extension is not supported on RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee,
RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems.
On HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt systems the number of bits per
component, represented internally, is the same for all components and
will be 4, 8, or 12 bits per component. All specified internal formats
will receive an equal or greater representation in this scheme, up to the
12-bit limit. HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt on Indigo2 systems do not
support texture internal formats of the type GGGGLLLL____IIIINNNNTTTTEEEENNNNSSSSIIIITTTTYYYY or GGGGLLLL____AAAALLLLPPPPHHHHAAAA,
although HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt on Octane systems do support
these types.
HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt on Indigo2 systems without the TRAM option
card support 4 bits per component for GGGGLLLL____RRRRGGGGBBBB and GGGGLLLL____RRRRGGGGBBBBAAAA, 4/8 bits per
component for GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE____AAAALLLLPPPPHHHHAAAA, and 4/8/12 bits per component for
GGGGLLLL____LLLLUUUUMMMMIIIINNNNAAAANNNNCCCCEEEE.
On RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems, the following
restrictions apply to 3D texturing:
1. The texture environment must be defined and texturing must be
enabled before loading a texture.
2. Texture formats composed only of alpha are not supported.
3. Borders are not supported; hence the border width must be 0.
4. Proxy textures are not supported.
5. 3D mipmaps are not supported. Hence, the minifying function must
be set to GGGGLLLL____NNNNEEEEAAAARRRREEEESSSSTTTT or GGGGLLLL____LLLLIIIINNNNEEEEAAAARRRR (see ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrr).
6 3D texturing when rendering to pixmaps is not supported.
7. GGGGLLLL____IIIINNNNTTTTEEEERRRRLLLLAAAACCCCEEEE____SSSSGGGGIIIIXXXX is not supported (see ggggllllEEEEnnnnaaaabbbblllleeee).
On HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt systems, the following restrictions
apply to 3D texturing:
1. Perspective views are not supported.
2. Borders are not supported; hence the border width must be 0.
3. 3D mipmaps are not supported. Hence, the minifying function must
be set to GGGGLLLL____NNNNEEEEAAAARRRREEEESSSSTTTT or GGGGLLLL____LLLLIIIINNNNEEEEAAAARRRR (see ggggllllTTTTeeeexxxxPPPPaaaarrrraaaammmmeeeetttteeeerrrr), and the
level parameter must be 0.
4. Textures that have a width of 16 or less will not render
correctly at the wrap_s boundary.
On OOOOccccttttaaaannnneeee2222 VVVVPPPPrrrroooo systems, 3D mipmapping is not supported. However, all
OpenGL state related to the GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____3333DDDD target is correctly error-
checked and queryable. For example, an incomplete mipmap stack results
in disabling 3D texturing, just as if 3D mipmapping were supported. The
only restriction is that, during rasterization, only the base level of
the texture is sampled. (The GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____BBBBAAAASSSSEEEE____LLLLEEEEVVVVEEEELLLL parameter may be used
to establish the base level of the texture; it need not be level 0.) For
3D texturing at rasterization time, the mipmapping forms of the
GGGGLLLL____TTTTEEEEXXXXTTTTUUUURRRREEEE____MMMMIIIINNNN____FFFFIIIILLLLTTTTEEEERRRR parameter are synonymous with the equivalent non-
Texture borders are not supported on IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy systems, so the
border width should always be zero. Applications should use the texture
wrap mode GGGGLLLL____CCCCLLLLAAAAMMMMPPPP____TTTTOOOO____EEEEDDDDGGGGEEEE____SSSSGGGGIIIISSSS to obtain behavior similar to that of
borders.
The SSSSGGGGIIIISSSS____tttteeeexxxxttttuuuurrrreeee____sssseeeelllleeeecccctttt extension is supported only on IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy
systems, HHHHiiiigggghhhh IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt on Octane systems, and HHHHiiiigggghhhh
IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt on Indigo2 systems with the TRAM option card.
On IIIInnnnffffiiiinnnniiiitttteeeeRRRReeeeaaaalllliiiittttyyyy, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee, RRRReeeeaaaalllliiiittttyyyyEEEEnnnnggggiiiinnnneeee2222, and VVVVTTTTXXXX systems, HHHHiiiigggghhhh
IIIImmmmppppaaaacccctttt and MMMMaaaaxxxxiiiimmmmuuuummmm IIIImmmmppppaaaacccctttt systems, and OOOOccccttttaaaannnneeee2222 VVVVPPPPrrrroooo systems, texture
objects (see ggggllllBBBBiiiinnnnddddTTTTeeeexxxxttttuuuurrrreeeeEEEEXXXXTTTT) are significantly faster than display-
listed textures, and therefore are recommended for managing texture
